Columbia Kermit/kermit.zip/newsgroups/misc.20010921-20020314/[e-mail]_Mon Nov 5 10:07:09 EST 2001.msg

Text File | 2020-01-01 | 9KB | 171 lines

Article: 12931 of comp.protocols.kermit.misc
Newsgroups: comp.unix.sco.misc,comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-peer.news.verio.net!news.verio.net!news.harvard.edu!news.fas.harvard.edu!newsreader.wustl.edu!unlnews.unl.edu!headwall.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!jfk3-feed1.news.digex.net!dca6-feed2.news.digex.net!intermedia!newsfeed1.cidera.com!Cidera!cyclone.nyroc.rr.com!news-east.rr.com!cyclone.kc.rr.com!news.kc.rr.com!nntp3.cerf.net!enigma.xenitec.on.ca!news.xenitec.on.ca!news
From: Bela Lubkin <[e-mail]>
Subject: Re: Dropping DTR in OSR5
Resent-From: [e-mail]
Submit-To: [e-mail]
Content-Type: text/plain; charset=us-ascii
Organization: [resent by] The SCOMSC gateway and Propagation Society
Content-Disposition: inline
Date: Mon, 5 Nov 2001 03:51:43 GMT
Message-ID: <[e-mail]>
User-Agent: Mutt/1.2.5i
To: [e-mail]
Mime-Version: 1.0
In-Reply-To: <9s4qjp$30k$[e-mail]>; from [e-mail] on Mon, Nov 05, 2001 at 01:39:05AM +0000
References: <9s40rp$fdh$[e-mail]> <3be5c667$0$439$[e-mail]> <[e-mail]> <9s4qjp$30k$[e-mail]>
Sender: [e-mail]
Precedence: list
Lines: 148
Xref: newsmaster.cc.columbia.edu comp.unix.sco.misc:139892 comp.protocols.kermit.misc:12931

Frank da Cruz wrote:

> In article <[e-mail]>,
> Bela Lubkin  <[e-mail]> wrote:
> : John DuBois wrote:
> : > ...
> : > Some problems in this area were fixed in 5.0.6a.  Please test on that
> : > release and see if you still encounter this problem.
> :
> : While this is true, Frank likes to support every OS ever made.  I
> : believe he still builds binaries for SCO Xenix.  A solution which
> : requires users to have an OS less than a year old won't satisfy him...
> :
> Strange but absolutely true.  People still run old -- even ancient --
> Unix OS's, including SCO Xenix.  Doctors' offices are a good place to
> look for computing antiques.  I know a doctor who runs his practice from
> an AT&T 3B2.  The billing package only runs there, the vendor disappeared
> decades ago...

It's a good thing you're doing, providing support for the stragglers.

> : The OpenServer "sio" driver doesn't implement ispeed and ospeed as
> : separate entities.  The functions exist and the structures have all the
> : necessary members, but it doesn't pay attention to the input rate, only
> : the output rate.  At least, that's how it's _intended_ to work.
> :
> Aha, the truth comes out...  Strict POSIX on the outside, not so strict
> on the inside :-)

Yep, just like every piece of software that claims adherence to any sort
of public standard...

> Actually a pet peeve of mine is how latter-day SCO header files (and
> most other vendors) are full of:
>
>   #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE)
>
> to keep you from getting at anything useful -- hardware flow control, for
> example.  In many cases also high serial speeds.  But I digress...

The devsys engineers at SCO (and perhaps today at Caldera) believed that
if you asked for POSIX compliance, you were asking the devsys to act as
a filter to prevent you from doing anything that wasn't specified in the
POSIX standard(s) in question; i.e. you were doing primary development
on this platform and wanted to be kept away from anything that would
make your code non-portable.  Most users, of course, think of these
flags as an _enabler_, "please _give_ me access to all the stuff implied
by such-and-such standard".  These are radically incompatible semantics.

The OSR5 devsys defaults to an "XPG plus" mode that is intended to give
you everything in all the standards the OS supports, plus whatever local
oddities exist.  Most cases where functionality is hidden behind an
ifdef like you show above, are probably bugs.  They _should_ say:

  #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) || defined(_XOPEN_SOURCE_EXTENDED)

I looked through the 13 header files that match, and some need to stay
the way they are; and changing any of them would probably break the
build of various already-ported programs.  So, probably shouldn't mess
with them.

> : I vaguely remember that you can get into trouble -- confuse the driver --
> : by trying to change both.  This might have been one of the things fixed in
> : rs506a.  But I think the problem can be avoided on all releases, by only
> : programming the output speed.  So, suppose you test with only changing
> : ospeed, see whether that makes a difference?
>
> I just tried this on 5.0.2 -- no difference.  DTR and RTS go down,
> but only DTR come back up.

Ok, so much for vague memories.

> : This also isn't a general solution.  There are third party drivers that
> : slot into the same ioctls, but _do_ correctly support independent i/o
> : speeds.  Does Kermit have any system-specific hint settings?  Something
> : like an OpenServer-specific "set ignore-ospeed", turned on by default?
> : "On" is the correct default since "sio" is the most common serial driver
> : on OpenServer, and split-speed usage is rather uncommon.
>
> The third-party drivers is a land I don't have a passport for.  Device
> names, lockfile conventions, who knows what else.  I have reams of
> correspondence on this stuff, and the conclusion is always "don't touch
> it".  I figure if Digi or Stallion or somebody wants Kermit to support
> their stuff, they'll contact me about it.

Hmmm, I would expect Kermit to just work with 3rd party drivers on OSR5.
Device names?  Kermit shouldn't care -- if I tell it "let's talk on
/dev/ttyi13A" it should say "ok, boss".  Lockfile convention are
something you have to work out between you and other user-level programs
(like the OS's `cu` and `uucico`), not with drivers; and the answers for
OSR5 are well known.

> : And, if I'm wrong, you might try an even kludgier workaround (which also
> : might not work, but is definitely worth trying): after having performed
> : all the POSIXly correct incantations, i.e. after the 2nd tcsetattr() in
> : your pseudo-code above, force an extra open of the port:
> :
> :   ...
> :   tcsetattr()
> :   if ((kludge_fd = open(the_port, O_RDONLY | O_NONBLOCK | O_NOCTTY)) >= 0)
> :     close(kludge_fd);
> :
> : I'm pretty sure this will cause "sio" to get its house in order and
> : raise DTR (and the close shouldn't lower it, since the other open still
> : exists).  For debugging purposes you might need to put in a pause before
> : the close() to observe that DTR actually goes on -- I don't fully trust
> : my assertion that the close() won't lower it.
>
> In fact DTR comes back on, but RTS stays down, just as without the kludge.
> The kludge does make a difference in 5.0.5, however: it makes it act like
> 5.0.2 (without the kludge in 5.0.5, both DTR and RTS stayed down).

Oh well.

> : One last thing.  There's a comment in the driver that implies that after
> : cycling the baud rate through 0, DTR might not come back up immediately;
> : might only come up when you output a character.  I'm pretty sure this is
> : fixed in rs506a, but for older releases, see whether outputting a NUL
> : after the 2nd tcsetattr() causes DTR to wake up.
>
> In 5.0.2 DTR came up anyway, but RTS does not come back up, even when you
> send bytes.   Ditto for 5.0.5 with and without all the above tricks.
>
> In short there seems to be no way to do this in OSR5 prior to 5.0.6a.  Hard

and you only have John's say-so with regard to 506a...

> to believe, right?  But not surprising either since I think Kermit must be
> the only program that would want to momentarily drop DTR without closing the
> device (and of course the problem with closing the device is that you've
> lost all the myriad setups you've done on it when you reopen it).

Well, no, people are asking all the time about what ioctls to use to
drop DTR momentarily.  Which is why John finally implemented TIOCMGET et
al for 506a; which of course doesn't help you.

One more trick you could do -- but which does more firmly tie you to
"sio".  If you're working on tty1a, open and close tty1A.  That should
be sufficient to kick RTS, DTR back to sanity.  And if you're working on
1A then open/close 1a.  None of which is particularly pleasant.  I might
also be wrong in that _opening_ might fix RTS & DTR, but closing might
screw them up again, so you would need to open and keep open the "other"
device node.  (Then, next time you need to do something to force correct
RTS & DTR, close and reopen that "other" port.)

yecch.

>Bela<